The present disclosure relates to a gas turbine engine and, more particularly, to a pressure spike filter algorithm therefor.
Gas turbine engines may include a Full Authority Digital Engine Control (FADEC) system that controls aspects of engine performance to allow the engine to perform at maximum efficiency for a given condition. The FADEC system also detects transient conditions such as an engine surge and triggers appropriate operational responses such as a surge recovery sequence to temporarily reduce engine thrust to facilitate clearance of the surge.
An Off Board Prognostics Health Monitor (OBPHM) processes Portable Memory Device (PMD) files to diagnose events that an engine or lift system undergo during a flight mission. The OBPHM also uses Health Report Code (HRC) data in the PMD file to determine the usage of the engine modules and generate reports of interests.
A PMD file is a collection of binary files that serve as a repository for HRC data. In one system, there can be a total of 16 binary files in what is considered a single PMD file, each having a maximum size of 12 MB, yielding a total size of 192 MB for a single PMD file. The HRC data stored within the PMD files is segmented into 1 KB packets that contain the HRC number, when the HRC event took place, among other HRC specific data elements, including transient data. There is no guarantee on the order that the data is written to the file due to the hardware implementation of the bus that generates the feed for these files, meaning that reading an entire HRC event sequentially is impossible.
An OBPHM is expected to be able to process 8 PMD files within a 3 hour time frame. Each file shall begin processing within 15 minutes of the previous file and should complete processing within a 30 minute window. In other words, an OBPHM is expected to process a maximum of 1536 MB worth of HRC data within 3 hours.
Previous implementations of an OBPHM evolved to handle slightly growing file sizes and were successful in meeting processing requirements at their respective time. As time passed however, larger and larger PMD files were made available for testing and the implementation for an OBPHM had to continue evolving to handle memory issues that were caused by the growing file sizes.
One concern with OBPHM operations is with the growth of file size. The typical OBPHM could handle a single file around the size of 24 MB to 36 MB depending on the amount of actual usage HRCs in the file. Beyond this point resulted in “Out of Memory” exceptions. These results fall extremely short of the requested amount of data to be processed and the processing time for a single file of the before mentioned sizes requires 2 to 3 hours to complete.
Evolution of the OBPHM application initially loaded all HRC data into memory through internal processes known as “Chunking, Reassembly, and Reconstruction”. This three-step approach to organizing the HRC data to enable an HRC event to be read sequentially for reporting purposes breaks down the files into 1 KB packet files (“Chunking”) The files are stored on disk in a folder structure that made it easy to identify which packets belonged to what HRC and HRC instance (“Reassembly”). The files were then read back into memory as objects representing an HRC, composed of HRC instances, which in turn stored packets worth of transient data (“Reconstruction”). The fact that such a large file was literally being transformed into objects in memory and that the Java Heap Memory by default has a size of only 64 MB is what lead to the memory issues. Simply put, the Java Heap Memory ran out of space to create objects representing the packets, instances, and HRCs.
Efficiently, this implementation is relatively fast and at the time was capable of processing smaller files of about 12 MB within an allotted 10 minute window. Subsequent changes to OBPHM lead to having the “Reconstruction” process only bring in the transient data for the usage and lifing some HRCs instead of all the HRCs. This promised to speed up the process somewhat and reduce the memory footprint of the application. However, this was not sufficient to cope with files as large as 24 MB. A potential solution to this issue involves offloading some of the memory usage to the database to cope with larger file sizes.
This approach effectively allowed an OBPHM to store usage HRC transient data in the database for later retrievable and reporting. On files as large as 36 MB the approach seemed to work but offloading the memory to the database came at a cost. The processing time was now in the hours instead of the minutes. “Out of Memory” exceptions still occurred although more sporadically under this approach.